Add Book to My BookshelfPurchase This Book Online

Chapter 5 - Adding Support for Legacy LANs

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Bridging Nonroutable Protocols
Some networking systems, such as Digital Equipment's LAT (Local Area Transport) do not define network numbers in packets sent out on a network. If a packet does not have a specific destination network number, a router will assume that the packet is destined for the local segment and will not forward it to any other network. In most cases this is the right thing to do; there are some instances, however, in which two devices need to communicate using a nonroutable protocol, and a router stands between them. One option to enable these two machines to communicate is to use the bridging capability of Cisco routers.
Figure 5-10: Forwarding NetBIOS packets through a Cisco router
INTERFACE ETHERNET 0
IPX NETWORK AAA
IPX TYPE-20-PROPAGATION
INTERFACE ETHERNET 1
IPX NETWORK BBB
INTERFACE ETHERNET 2
IPX NETWORK CCC
IPX TYPE-20-PROPAGATION
Figure 5-11: Configuration for the router in Figure 5-10
Before we get into the specifics of using a Cisco router as a bridge, let's review the operation of the two types of bridge that have been widely implemented in the market, transparent bridges and source route bridges. What has ended up being available in the marketplace are bridges that typically do both transparent and source route bridging. A device acting as this type of bridge will act as a transparent bridge if the layer 2 header does not contain a Routing Information Field, and will act as a pure source routing bridge if there is a Routing Information Field. The following will discuss the operation of transparent and source route bridging separately.
Transparent Bridges
The transparent bridge was developed to allow protocols that were designed to operate on only a single LAN to work in a multi-LAN environment. Protocols of this type expect a packet to be received by the destination workstation to arrive unaltered by its progress through the LAN. The basic job of a transparent bridge, therefore, is to receive packets, store them, and retransmit them on other LANs connected to the bridge, making it useful for extending the limits of a LAN.
In a Token-Ring environment, a transparent bridge can increase the number of workstations on a ring. Each time a token gets passed from workstation to workstation on a ring, the clock signal degrades. A transparent bridge can be used to connect two physical rings and allow more workstations to be connected because it uses a different clock and token for each ring. As far as any layer 3 software is concerned, however, the two rings are still on the same network number.
A transparent bridge will do more than this, though, because a learning bridge will "learn" which MAC addresses of workstations are on which LAN cable and either forward or block packets according to a list of MAC addresses associated with interfaces kept in the bridge. Let's examine how the bridge operates in the multi-LAN environment of Fig. 5-12.
Figure 5-12: Transparent bridge operation
First it must be noted that as far as any layer 3 protocols, such as IP or IPX are concerned, LAN 1 and LAN 2 in this figure are the same network number. The process operated by the transparent bridge is as follows:
  Listen to every packet on every interface.
  For each packet heard, keep track of the packet's source MAC address and the interface from which it originated. This is referred to as a station cache.
  Look at the destination field in the MAC header. If this address is not found in the station cache, forward the packet to all interfaces other than the one on which the packet was received. If the destination address is in the cache, forward the packet to only the interface the destination address is associated with. If the destination address is on the same interface as the device originating the packet, the packet is dropped; otherwise duplicate delivery of packets for that packet would result.
  Keep track of the age of each entry in the station cache. An entry is deleted after a period of time if no packets are received with that address as the source address. This ensures that if a workstation is moved from one LAN to another, the "old" entry in the station cache associating that address with a now incorrect interface is deleted.
Using this logic, and assuming that workstations A, B, C, and D in Fig. 5-12 all communicate with one another, the bridge will produce a station cache that associates workstations A and B with interface 1, then C and D with interface 2. This potentially relieves congestion in a network. All traffic that originates at and is destined for LAN 1 will not be seen on LAN 2 and vice versa.
This form of bridging works well for any LAN topology that does not include multiple paths between two LANs. We know that multiple paths between network segments is desirable to maintain connectivity if one path fails for one reason or another. Let's look at what a simple transparent bridge would do if implemented in a LAN environment such as that shown in Fig. 5-13.
Figure 5-13: Network with multiple bridge paths between LANs
Let's say this network is starting up and the station cache for both bridge A and B are empty. Suppose a workstation on LAN 1—let it be termed "workstation X"—wants to send a packet. Bridges A and B will receive this packet, note that workstation X is on LAN 1, and queue the packet for transmission onto LAN 2. Either bridge A or bridge B will be the first to transmit the packet onto LAN 2; for argument's sake, say bridge A is first. This causes bridge B to receive the packet with workstation X as the source address on LAN 2, since a transparent bridge transmits a packet without altering header information. Bridge B will note that workstation X is on LAN 2 and will forward the packet to LAN 1. Bridge A will then resend the packet to LAN 2. You can see that this ends up a nasty mess.
Because a routed network typically will have multiple paths between LANs, turning on bridging capability could be as disastrous as in the example above if it were not for the spanning tree algorithm implemented on Cisco routers.
The Spanning Tree Algorithm.     The spanning tree algorithm exists to allow bridges to function properly in an environment having multiple paths between LANs. The bridges dynamically select a subset of the LAN interconnections that provides a loop-free path from any LAN to any other LAN. In essence, the bridge will select which interfaces will forward packets and which will not. Interfaces that will forward packets are considered to be part of the spanning tree. To achieve this, each bridge sends out a configuration bridge protocol data unit (BPDU). The configuration BPDU contains enough information to enable all bridges to collectively:
  Select a single bridge that will act as the "root" of the spanning tree.
  Calculate the distance of the shortest path from itself to the root bridge.
  Designate, for each LAN segment, one of the bridges as the one "closest" to the root. That bridge will handle all communication from that LAN to the root bridge.
  Let each bridge choose one of its interfaces as its root interface, which will gives the best path to the root bridge.
  Allow each bridge to mark the root interface—and any other interfaces on it that have been elected as designated bridges for the LAN to which it is connected—as being included in the spanning tree.
Packets will then be forwarded to and from interfaces included in the spanning tree. Packets received from interfaces not in the spanning tree are discarded and packets are never forwarded onto interfaces that are not part of the spanning tree.
Configuring Transparent Bridging.     When configuring a Cisco router to act as a transparent bridge, you need to decide the following before entering any configuration commands into the router:
  Which interfaces are going to participate in bridging and what the bridge group number for these interfaces will be.
  Which spanning tree protocol to use.
In Fig. 5-14 we have a router with four interfaces, three of which belong to bridge group 1. If the router had more interfaces, and if a second group of interfaces were chosen to form a bridge group, the two bridge groups would not be able to pass traffic between them; in effect, different bridge groups act as different bridges and do not pass configuration BPDUs between them. In the example of Fig. 5-14, IP traffic is routed between the interfaces and all other protocols are bridged.
In the configuration of the router in Fig. 5-14, the bridge protocol command defines the spanning tree algorithm to use; for transparent bridging that is either IEEE or DEC. This value must be consistent between all routers forming part of the same spanning tree. The group number is a decimal number from 1-9 that identifies the set of bridged interfaces. This configuration command option is implemented in case you want to set up on the same router sets of interfaces that belong to different bridging groups.
Figure 5-14: Network and router configuration for basic transparent bridging
In Fig. 5-14, router A has been configured for Ethernet 0, Ethernet 1, and Serial 0 to be part of bridge group 1. This bridge group number has significance only within router A, where it identifies the interfaces that will participate in bridging on that router. Router B has bridge group 1 defined as well. Again, this has relevance only within router B. Packets could just as well be bridged between routers A and B if the Serial 0, Ethernet 0, and Ethernet 1 interfaces on router B were made part of bridge group 2.
Extending transparent bridging to include dozens of Cisco routers is a simple matter, as the same configuration given here is replicated on each router to be included in the spanning tree. As long as each router to be included in the spanning tree has an interface that is configured to bridge transparently, and is connected to an interface on another router that is configured to bridge transparently, all such routers will be included in the spanning tree.
Source Routing Bridges
Source routing at one time competed with transparent bridging to become the 802.1 standard for connecting LANs at the layer 2 level.
When spanning tree bridges became the preferred 802.1 standard, source routing was taken before the 802.5 committee and was adopted as a standard for Token-Ring LANs. As such, it is only really used when connecting Token-Ring LANs.
The idea behind source routing is that each workstation will maintain in its memory a list of how to reach every other workstation; let's call this the route cache. When a workstation needs to send a packet, it will reference this route cache and insert route information in the layer 2 header of the packet, telling the packet the exact route to take to reach the destination. This route information is in the form of a sequence of LAN and bridge numbers that must be traversed in the sequence specified in order to reach the destination.
Let's look at Fig. 5-15, which shows the regular layer 2 header and one that is modified to participate in source route bridging. To inform a receiving node that the packet has source route information rather than user data after the source address, the multicast bit in the source address is set to 1. Prior to source route bridging, this multicast bit was never used.
Figure 5-15: Layer 2 headers with and without the source multicast bit set
If a workstation needs to send a packet to a destination not currently in the route cache, this workstation will send out an explorer packet addressed to that destination. An explorer packet traverses every LAN segment in the network. When an explorer packet reaches a bridge on its travels and could travel one of many ways, the bridge replicates the explorer packet onto every LAN segment attached to that bridge. Each explorer packet keeps a log of LANs and bridges through which it passes.
Ultimately the destination workstation will receive many explorer packets from the originating workstation and will, by some mechanism, tell the originating workstation the best route to enter into the route cache. Whether the destination or originating workstation actually calculates the route information, and what the exact details of the best route are, is open to vendor implementation and not specified in the standards.
Configuring Source Route Bridging.     The first difference between transparent bridging and source route bridging becomes apparent when we look at the configuration commands. In transparent bridging, it was necessary only to identify the interfaces on each router that were to participate in transparent bridging and the spanning tree algorithm would work out which interfaces on each router in the spanning tree would be used for forwarding packets. Source route bridging is not so simple and requires every LAN and every source route bridge to be uniquely identified in the network. Configuration of a Cisco router for source route bridging is simple if we consider a bridge that has only two interfaces configured for source route bridging, as shown in Fig. 5-16. This then becomes a matter of bridging between pairs of Token-Ring LANs.
Figure 5-16: A simple source route bridge network
The following commands configure the Token-Ring 0 and Token-Ring 1 ports for source route bridging.
Router1(config)#interface to 0
Router1(config-int)#source-bridge 10 2 11
Router1(config-int)#interface to 1
Router1(config-int)#source-bridge 11 2 10
The first source bridge configuration command arguments for the Token-Ring 0 interface can be explained as follows:
  The local ring number for interface Token-Ring 0 is in this case 10, but it can be a decimal number between 1 and 4095. This number uniquely identifies the ring on that interface within the bridged network.
  The bridge number, which must be between 1 and 15, is in this case 2, and it uniquely identifies the bridge connecting the two rings within the bridged network.
  The target ring, which is the network number of the second ring in the ring pair, must be between 1 and 4095, and in this case is 11.
The second source bridge command is for the Token-Ring 1 port and merely reverses what this interface sees as the local and destination ring.
If a bridge has more than two interfaces that need source route bridging, an internal virtual ring needs to be defined and each "real" interface is bridged to the virtual ring. This configuration is shown in Fig. 5-17, with each external ring (100, 101, and 102) individually bridged to the internal ring 20, via router 1, which is identified with a source route bridging number of 5. ("Router 1" is the configured hostname of the router.)
Figure 5-17: A source route bridging for more than two LANs
It is worth noting that source route bridging has significance only on Token-Ring interfaces. If you are using a Cisco access server to provide remote dial-up services to a Token-Ring LAN, the dial-up ports will not use a Token-Ring encapsulation; they will probably use PPP. Network administrators may be forgiven for thinking that since all workstations on a LAN must have source routing enabled to get access to servers on remote rings, the dial-up workstations would need this too. This is, in fact, not the case. As the dial-up workstations are using PPP as a layer 2 protocol, there is no place to insert source route information in the layer 2 header.
Source Route Transparent Bridging
What is implemented in the main is source route transparent bridging, in which a bridge will use source routing information if the multicast bit in the source address is set to 1 (this bit is now known as the Routing Information Indicator), and transparent bridging if the Routing Information Indicator is not set. Figure 5-18 shows a bridged network with a router configuration for both source route and transparent bridging.
The tasks to be accomplished when configuring a router to perform both transparent and source route bridging are as follows:
  For transparent bridging on Ethernet interfaces, define a transparent bridge process and associate a number with it.
  Define which spanning tree algorithm will be used by the Ethernet ports.
Figure 5-18: Router configuration for source route transparent bridging
  Define an internal ring that can be paired with all external token rings.
  Define the automatic spanning tree function for the source route network. Note that the interfaces in a source route network can transparently bridge packets. The interfaces in a source route network will, however, define a separate spanning tree from the transparent bridge interfaces in the Ethernet network.
  Associate each Ethernet port with a specific bridge group.
  Enable the spanning tree function for each interface to be part of the source-route-based spanning tree.
  Associate each Ethernet and Token-Ring port with a transparent bridge group.
It seems complicated—and it is. I do not mind admitting that I do not like bridging, and I think that source route bridging does not scale well in a network of any size. Most people these days will use a layer 3 protocol (either IP or IPX), so there is little need to try to muscle layer 3 functionality into a layer 2 protocol. Having said that, if you really do have to implement source route transparent bridging and need to understand the commands shown in Fig. 5-18, an explanation follows.
The bridge 5 protocol ieee command defines a transparent bridge process with ID 5. This command partners with the interface command bridge-group 5 that identifies all the interfaces to be part of this transparent bridge group. The source-bridge ring- group 9 command defines the internal virtual ring with which all external rings will be paired. The bridge 8 protocol ibm command defines the spanning tree algorithm for this router and associates it with an ID of 8. This command partners with the interface command source-bridge spanning 8 that identifies all Token-Ring ports that will participate in defining the spanning tree for the Token-Ring side of the network. The final command is the source-bridge 200 1 9 command, which gives this bridge a source route bridging ID of 1 and links the Token-Ring network number on the specific interface (in this case 200) to the internal virtual token ring (number 9).

 


 
Books24x7.com, Inc © 2000 –  Feedback